chore(cli): migrate changes for Capacitor 9#8521
Conversation
jcesarmobile
requested review from
ItsChaceD,
OS-pedrogustavobilro,
OS-ruimoreiramendes,
alexgerardojacinto,
andredestro,
eric-horodyski,
markemer and
theproducer
| if (txt.includes('@main')) { | ||
| return; // Probably already updated | ||
| } | ||
| // Since navigation was an optional change in Capacitor 7, attempting to add density and/or navigation |
There was a problem hiding this comment.
This comment seems out of place? It sounds it's referring to changes in Android Manifest but this is AppDelegate.
| // eslint-disable-next-line prefer-const | ||
| let allDependencies: { [key: string]: any } = {}; | ||
| const libs = ['@capacitor/core', '@capacitor/cli', '@capacitor/ios', '@capacitor/android']; | ||
| const plugins = [ |
There was a problem hiding this comment.
If this year we'll be launching next versions for all official plugins (I think we are aiming to do that?), should we update this list perhaps?
There was a problem hiding this comment.
While I suppose for this PR it would mean pointing everything to next, when Cap 9 rolls out we'd need to adapt this script to map other plugin versions that aren't 9.x (e.g. barcode scanner)
That being said, since they are official plugins, they should be here in this script?
| const pluginVersion = 'next'; | ||
| const gradleVersion = '9.5.1'; | ||
| const iOSVersion = '16'; | ||
| const kotlinVersion = '2.4.0'; |
There was a problem hiding this comment.
Should we no longer be replacing kotlin version for classpath, and instead remove it? Because it's now bundled in AGP 9?
We added it in Capacitor 8 to fix an issue related to an app declaring the kotlin version in root build.gradle and it differing from the one Capacitor / Plugins use. Internal Slack Thread. But AGP bundles kotlin gradle plugin it's probably better to not have it in the app, and instead remove it altogether perhaps?
But also, we are using Kotlin 2.4.0 here and AGP 9.2 uses 2.3.10. But since it's a minor version change it should be ok (where last year it was a major version).
If you think this is better left to a separate task / PR let me know, but just wanted to highlight it.
| }); | ||
| } | ||
| replaced = replaced.replace(`proguard-android.txt`, `proguard-android-optimize.txt`); | ||
| replaced = replaced.replace(' targetSdkVersion rootProject.ext.targetSdkVersion\n', ''); |
There was a problem hiding this comment.
In AGP 9, users can change the behavior of targetSDK by setting android.sdk.defaultTargetSdkToCompileSdkIfUnset to false in gradle.properties - in which case it would default to the minSdk, which would break the app (don't know if it would compile, but you wouldn't be able to submit to play store). This will no longer be possible in AGP 10 (there's a warning in gradle related to this).
I don't know why anyone would do this voluntarily, but they could if they want to. What seems more likely to happen is users that migrated to AGP 9 while in Capacitor 8 - android.sdk.defaultTargetSdkToCompileSdkIfUnset=false; I tested Android Studio's AGP migration assistant and it adds that property.
So the way to overcome this issue would be one of or a combination of:
- Keep
targetSdkVersionfor now. Only remove it in a future version whenever we move to AGP 10. This would maybe require re-changing the template (although the template is new Capacitor apps, this point I'm making would be more for existing ones). For plugins it doesn't really matter iftargetSdkVersionis there or not, because we don't run plugins on-device, only apps. - Have the migrate command remove the properties added - Probably in a separate PR because I'm seeing there may be other properties that we may need to update for AGP 9. While I think we should do that, it has the nefarious effect of potentially removing flags that the particular Capacitor app needed, but there's no way for us to know if they were added automatically by Android Studio and have no actual impact, or if they have specific flags to fix specific issues in their native setup - will post more info on that internally in the next couple of days.
Let me know if this makes sense, and if you have a preference on the approach (only 1., only 2., both, other...)
2 participants
The links to the docs don't exist yet, we should create them before releasing this, but the docs tasks are not on the sprint.
Also it will probably need some more changes in the future depending on what breaking changes we make in the plugins or if we make more changes on the templates.